A Virtual Private Network (VPN) is a private network created over a public network where exclusive client and host communications occur. A conventional VPN connects users or sites over a public network, usually the Internet. Virtual privacy is derived from secure tunnels that encapsulate the data as it moves across the shared lines. The VPN enables a user to securely send data between two computers across a shared, public network in a manner that emulates the security properties of a private point-to-point link.
However, the conventional protocol for a remote access (RA) client (a client for creating an Internet connection) communicates the login credentials of the users in an unsecured fashion. If a user maintains identical login credentials for RA authentication and VPN authentication, then the VPN is compromised if the user's RA credentials are stolen. Accordingly, a VPN using a conventional VPN client is vulnerable to the extent the user's RA credentials are vulnerable.
FIGS. 1 and 2 illustrate the conventional RA authentication methods and security levels. RA client 10 running on computer 11 accesses server 90 over Internet 40. For example, a typical Internet dial-up connection uses either Password Authentication Protocol (PAP) or Challenge-Handshake Authentication Protocol (CHAP) over Point-to-Point Protocol (PPP) for transporting user credentials to the Internet service Provider's (ISP's) dial access server 30 or network access server (NAS) 42. Remote Authentication Dial-In User Service (RADIUS) is used to transport user credentials between the NAS, the ISP and server 90. PAP transmits user identification (ID) and password credentials in clear text between the personal computer 11 (PC) and the NAS. Between the NAS and the RADIUS server, the username is in the clear (i.e., not encrypted), followed by a hashed password using a shared secret setup between the NAS and the RADIUS server.
CHAP utilizes a three-way handshaking process. Once the link has been established, the server sends a challenge message to the originating device. The originating device responds back with a value that is calculated using the user password and a one-way hash function. The server checks the response against its own calculation of the expected hash value. If the values match, the authentication is accepted. CHAP transmits user ID in clear text, but a hash of the password. RADIUS transmits the user name in clear text followed by a hashed password using a shared secret setup between the NAS and the RADIUS server.
One or more ISPs may be involved in the authentication transaction, especially when cross-provider network roaming services are being used. In these situations, the RADIUS protocol is normally used for relaying authentication requests and responses between authentication entities. In these transactions, the user ID is normally transmitted in clear text, although the password is transmitted in encrypted form. However, the password is decrypted and re-encrypted at each ISP involved in the transaction.
Even when the user is accessing the Internet via a wireless networking (Wi-Fi) hotspot, roaming broadband or some other method, and the initial hop of the authentication process secures the user's ID and password via Secure Sockets Layer (SSL) encryption, the ID and password must still be decrypted by the local ISPs before being transmitted via RADIUS. Thus even in these situations, encrypted user ID and passwords are not necessarily protected from theft. In fact, the user ID and password are subject to theft whenever they are communicated in clear text, whether by unscrupulous ISP employees, or others who have hacked into the ISP network. These conventional RA authentication processes are shown in FIG. 3. Accordingly, RA credentials are vulnerable to compromise, potentially leading to theft of Internet access services, and compromise of a VPN accessed by credentials identical to the RA credentials.
Two security products created for authenticating connections to local area networks (LANs) are called ACESERVER and SECUREID (marketed by RSA Security, Inc. an industry leading authentication products supplier). These two products are a tightly coupled system. The SECUREID is a pseudo-random number generator, which outputs a new value every minute. When a SECUREID user is authenticating their login they input their user ID as usual. However instead of entering a reusable password, they enter a personal identification number (PIN) as well as the then-current random number displayed on the SECUREID device. The combination of a pseudo-random number and a PIN is often referred to as a passcode. The authentication request is transmitted over the network (or networks) and ultimately to the ACESERVER. The ACESERVER applies an algorithm to determine what the then-current random number should be for that user and then makes an authentication decision.
The ACESERVER supports a periodic administratively forced PIN reset functionality just as other authentication applications support administratively forced password reset functionality. This is called a “New PIN Challenge.” When a PIN reset is required, instead of acknowledging the authentication request, the ACESERVER sends a “New PIN” challenge command to the user. The ACESERVER also supports a periodic random challenge to the user. This is called a “Next Token Challenge.” This is done when an authentication failure occurs (e.g. the PIN or random numbers provided by the user do not match those calculated by the ACESERVER). When a new random number (the “token”) is required, instead of acknowledging the authentication request, the ACESERVER sends a “Next Token” challenge command to the user.
Conventional dial-up Internet networks and networking protocols (e.g. PAP and CHAP) do not support the notion of sending challenges to the user. The user's computer initiates a connection request, the dial in server commands the user's computer to respond with a user ID and password via either the PAP or CHAP dial authentication protocols. The user's computer responds with the appropriate values and the dial in server transmits them to the ISP. The dial-in server then waits for either an authentication success or authentication failure response. No other response types are supported, including challenge commands originating from an RSA ACESERVER. If either of these message types were returned from the ACESERVER to the dial in server, authentication would fail, as they are unrecognized message types. The present inventors are unaware of systems using a challenge response system such as the ACESERVER and SECUREID for authenticating Internet access.
Further, a conventional VPN client application allows a remote user to establish a direct connection to a corporate network when not on the premises of the corporation. When connecting in this fashion, the connection bypasses the usual corporate network security measures (e.g. firewalls and anti-virus servers). By permitting remote users to bypass the network security perimeter, enterprises run a significant risk that a user establishing a VPN connection to the corporate network is doing so from an unsafe and/or already “infected” machine. This connectivity from an unsafe computer creates a risk that the computer could be used as source of an attack on the network without the end user being aware of it.
Accordingly, a secure means of remote access to a computer system is needed.